Master test plan self-evident?

While creating a master test plan may seem self-evident, it is not that easy in actual practice. Unfortunately, the test managers of the individual test levels are often expected to achieve alignment. While agreement can usually be reached at the level of milestones, it becomes more difficult when involving the scope and thoroughness of the various test levels. A project manager is generally unable to devote adequate attention to this, while the test manager of a separate test level does not have the right authorisations. Fortunately, the importance of tuning and maintaining alignment of the test levels is understood more and more often in system development. For instance, in IBM’s system development method, Rational Unified Process®, the master test plan is a formalised product.

Creating a master test plan and managing the total test process requires a specific role: the test manager or overall test coordinator for the overall test process.

‘Unnecessary double testing’

An important reason for a master test plan is preventing unnecessary double testing. The word ‘unnecessary’ is important in this context. As such, double tests are not a problem; often they cannot be avoided, and in some cases they are even mandatory. In a unit test, for instance, the same functionality will often be tested as in a system test, and various test cases will resemble each other. Part of the system test may also be repeated on purpose in the acceptance test, e.g. to check that everything works on the production-like infrastructure or within existing business processes. An example of ‘unnecessary double’ is when two test levels use a similar test design technique to derive and execute similar test cases.